3 运输层主要协议 TCP 概述
3.1 TCP概述 特点
TCP是面向连接的运输协议
- 每一条TCP只能有两个端点，点对点
- 提供可靠的全双工交付
- 面向字节流，但占用很多资源
- 不提供广播和多播服务
所以从某种意义来说
UDP是一种更加有效的工作方式
TCP面向流的概念
把字节写入发送缓冲，加上TCP首部构成TCP报文段，从接收缓存读取字节，到接收方
3.2 TCP连接
TCP的连接端点叫做套接字（端口号拼接到IP地址构成了套接字）
套接字socket=（IP地址：端口号） 如(192.268.2.2:80)
对于要实现传送，可靠传送，拥塞控制等，某些状态信息是必要的。从发送方主机和接收方主机上预留的资源，中间系统不必为主机预留资源
RSVP资源预留协议
是在终端和路由器之间进行业务质量参数协商的信令协议
商量预留带宽和缓冲区的大小
双向资源预留
TCP可靠传输明白数据分组中的序号代表发送的起始位置，确认号
4 TCP可靠传输
4.1 可靠传输工作原理
4.1.1 停止等待协议
就是每发送完一个分组就停止发送，等待对方确认，在收到确认之后再发送下一个分组
全双工通信的双方既是发送方也是接收方
假设我们发送方是A，接收方是B
发送消息$M_0,M_1……$
无差错情况
即A发送，B确认后正常返回确认信息
出现差错
出现差错有两种情况
情况一：发送信息没有到达接收方B，接收方B自然不会向发送方A传输确认信息
情况二：接收方B检测出了错误，直接丢弃，也不会给发送方A传输确认信息
那么A怎么判断是否出现差错呢？就是通过超时重传（设置一个超时计时器） 等一段时间如果没有收到确认信息，则认为传输差错，重传
确认丢失和确认迟到
这种情况发生在接收方向发送方发送确认信息的时候，确认信息丢失
导致A以为B没有正确收到，就会导致重复发送M信息，然后B收到重复的M之后，处理是
第一步 丢弃重复的M
第二步 向A再发送确认信息
停止等待协议优点是简单
缺点是信道利用率太低
采用了流水线式的传输
4.1.2 连续ARQ协议
连续ARQ协议会设置一个滑动窗口，窗口内部的是可以进行发送的，发送方每收到一个确认，就把发送窗口向前移动一个分组的位置。
接收方一般都采用累积确认方法，也就是说不必逐个发送确认，而是收到几个分组之后，对按序到达的最后一个分组发送确认（这就表示到目前为止所有分组发送都正确的）
优点是：容易实现
缺点是：不能向发送方及时反映接收方收到的消息
4.2 TCP可靠通信的具体实现
具体实现方式之前，先了解TCP报文段首部格式
TCP面向字节流，但是传输单元是报文段
一个TCP报文段分为首部和数据两部分，而TCP的全部功能体现在它首部中各字段的作用。
TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项
4.2.1 以字节为单位的滑动窗口
首先对于发送方有一个发送窗口，接收方有一个接收窗口
发送方根据接收方传来的确认号与自己的发送窗口大小构建窗口或者移动窗口
接收方不断确认，然后按序交付给高层
4.2.2 超时重传时间的选择
$RTO=(1-\alpha)RTO+\alpha RTT$
前面我们讲到TCP发送方在规定时间没有收到则要进行重传
重传时间的选择是非常复杂的
TCP采用了一种自适应的算法
它记录一个报文段发送出去的时间，以及收到相应的确认的时间。这两个时间之差就是**报文段往返时间$RTT$**，为了结果更加平滑，引入了加权平均往返时间$RTT_s$
每测量一个新的RTT样本，进行一次重新的计算
$新RTT_S=(1-a)×(旧的RTT_S)+a×(新的RTT样本)$
a是一个常数，一般选择0.125
最后我们的超时重传时间RTO应略大于上面得出的加权平均往返时间$RTT_S$
实际计算
$RTO=RTT_S+RTT_D$
$RTT_D$是RTT的偏差加权平均值
4.2.3 选择确认SACK
还有一个问题，就是如果收到的报文没有差错，只是未按序号，中间还缺少一些
那么能否只传输缺少的数据，而不传输已经正确到达的
是可以的，选择确认就是一种可行的处理方法SACK
这个SACK是可以选择的，双方通信可以约定好，如果使用的话会造成更大开销
5 TCP的流量控制
一般来说，我们总是希望数据传输的快一些，但是如果发送方数据传输过快，那么接收方就来不及接收而造成数据丢失，所以需要流量控制——让发送方的发送速率不要太快，让接收方来得及接收
5.1 滑动窗口实现
实际就是通过如果发送方发现发过去会导致丢失，那么则减小滑动窗口的大小
- 糊涂窗口综合征：当发送方和接收方对滑动窗口的大小以及如何控制它的方式存在一些不一致或不清晰的理解时，就会出现糊涂窗口综合征。这可能导致以下问题：
- 窗口过小：如果接收方认为滑动窗口太小，无法有效利用可用的带宽，可能会导致数据传输速度变慢，从而浪费了网络资源。
- 窗口过大：如果发送方认为滑动窗口可以更大，但接收方不能及时处理或确认所有数据包，就会导致拥塞和丢包问题。
- 滑动窗口不同步：如果发送方和接收方之间的窗口大小或滑动窗口控制逻辑不一致，可能会导致数据包的重传和混淆，从而使网络性能下降。
- 解决方法：要解决糊涂窗口综合征，需要确保发送方和接收方之间对于窗口大小和滑动窗口控制的方式达成一致。这可以通过更好地协调和调整滑动窗口参数，以及在网络中实施拥塞控制策略来实现。
$最大吞吐量=\frac{窗口大小}{RTT}$
注意需要统一单位 最大吞吐量是bit/s
所以窗口大小=字节数*8 RTT要转换为s
6 TCP拥塞控制
6.1 拥塞控制一般原理
当对网络中的某一资源的需求大于网络能够提供的资源时，则会产生拥塞，导致网络性能变坏，因而要进行拥塞控制
6.2 拥塞控制的方法
1 慢开始
拥塞窗口用来反映当前网络的这个拥塞情况，越大说明越拥塞
用来确定网络的负载能力，核心由小到大逐渐增大拥塞窗口数值
初始拥塞窗口cwnd的设置：
旧规定，先把初始拥塞窗口cwnd设置为1到2个发送方最大报文段SMSS的数值
新的RFC 5681 把初始拥塞窗口cwnd设置为不超过2到4个SMSS数值
慢开始门限
拥塞窗口控制方法：
在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值
使用慢开始算法后，没经过一个传输轮次，拥塞窗口cwnd就加倍
一个传输轮次所经历的时间就是往返时间RTT。传输轮次更加强调：把拥塞窗口cwnd所允许发送的报文段都连续
设置一个慢开始门限ssthresh，
当cwnd<ssthresh 使用慢开始算法
当cwnd>ssthresh 改为使用拥塞避免算法
2 拥塞避免
让拥塞窗口缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口+1，而不是加倍，使拥塞窗口cwnd按线性规律缓慢增长
因此，在拥塞避免阶段就有点“加法增大”特点
当出现拥塞的时候，减少分组数
3 快重传
让对方尽早知道发生了个别报文段的丢失
快重传算法首先要求接收方不要等待自己发送数据才进行捎带确认，而不是立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
当发送方一连收到三个重复确认，就知道接收方确实没有收到报文段，因而立即进行重传
4 快恢复
当发送方一连收到三个重复确认，不认为此时发生了拥堵
因而不执行慢开始算法，而是执行快恢复算法
主动队列管理AQM
就是不要等到路由器的队列长度已经达到最大值的时候才不得不丢弃后面到达的分组，这样就太被动了
应当在队列长度到达某个值得警惕的数值时，就主动丢弃到达的分组
7 TCP运输连接管理
7.1 TCP的建立
TCP建立的过程叫做握手
握手需要再客户和服务器之间交换三个TCP报文段，称之为三报文段握手
采用三报文段握手主要为了防止已失效的连接请求报文段突然又传送到了，因而产生错误
7.2 TCP的连接释放
四次握手
为什么四次，核心原因就是因为全双工的原因！
TCP的有限状态机
